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DEVELOPMENT  AND 
ANALYSIS  OF  INTEGRATED 
C4ISR  ARCHITECTURES 

Kristin  Giammarc o,  Michael  Carlomusto,  and  J.  D.  Lock 


The  U.S.  Army  continues  to  struggle  with  creating  doctrinally  correct,  robust, 
consistent,  and  all-inclusive  operational,  system,  and  technical  views  based  on 
the  Department  of  Defense  Architecture  Framework.  Having  detailed,  integrated, 
and  up-to-date  architecture  views  is  essential  to  answering  questions  involving 
alternative  system  designs  and  operating  procedures,  conducting  gap,  overlap, 
and  connectivity  analyses  among  programs  of  record,  and  providing  traceable  data 
upon  which  to  base  near-  and  far-term  acquisition  decisions  as  the  armed  services 
undergo  Transformation.  This  paper  presents  an  overview  of  the  Communications- 
Electronics  Research,  Development,  and  Engineering  Center  Command,  Control, 
Communications,  Computer,  Intelligence,  Surveillance,  and  Reconnaissance 
(C4ISR)  methodology  for  developing  and  utilizing  integrated  architecture 
products  for  the  purposes  of  C4ISR  System-of-Systems  engineering  analyses. 


in  support  of  Army  leadership’s  efforts  to  make  prudent  and  efficient  acquisition 
decisions  at  the  system-of-systems  level,  the  Research,  Development,  and 
Engineering  Command  (RDECOM),  Communications-Electronics  Research, 
Development,  and  Engineering  Center  (CERDEC)  has  developed  a  structured  and 
repeatable  methodology  for  producing  and  analyzing  integrated  Command,  Control, 
Communications,  Computer,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR), 
Department  of  Defense  Architecture  Framework  (DoDAF)  (DoDAF  Architecture 
Framework  Version  1,  2003)  products.  This  integrated  architecture  process  is  a  major 
component  of  the  larger  CERDEC  Systems  Analysis  Processes  and  Tools  (CSAP&T) 
methodology,  which  is  a  comprehensive  systems  engineering  approach  to  the  integration 
of  architecture,  Modeling  and  Simulation  (M&S),  and  experimentation  activities  at 
CERDEC.  Architecture  products  are  used  by  CERDEC  as  vehicles  for  storing  and 
relating  essential  information  for  analysis.  They  are  designed  to  contain  information 
needed  for  M&S,  and  be  validated  and  updated  based  on  virtual,  live,  and  constructive 
experimentation. 
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The  process  described  in  this  paper  has  evolved  over  the  course  of  numerous  studies 
done  by  the  CERDEC  Architecture  and  Systems  Engineering  Office  (ASEO)  for  various 
Army  customers,  growing  in  fidelity  and  capability  with  each  study.  It  is  implemented 
at  CERDEC  using  a  tool  called  The  Complete  C4ISR  Architectural  Tool  (TCAT),  which 
was  developed  by  CERDEC  to  meet  specific  M&S  requirements  for  the  architecture 
products  and  to  improve  traceability  and  reusability  of  data.  The  TCAT  consists  of 
a  relational  database  with  customized  structured  query  language  (SQL)  scripts  that 
present  architecture  information  in  the  form  of  human-readable  operational  and  system 
views  and/or  data  files  for  use  in  other  databases  or  spreadsheet  programs,  as  well  as 
M&S  network  simulation  tools  such  as  OPNET  and  QualNet.  The  TCAT  database  has 
been  designed  to  be  “tool  agnostic,”  meaning  data  can  be  moved  into  and  out  of  TCAT 
as  long  as  a  common,  specific  data  model  is  used.  One  of  the  specific  data  models  used  is 
an  Extensible  Markup  Language  (XML)  implementation  of  the  Core  Architecture  Data 
Model  (CADM).  The  CADM  XML  tables  are  used  to  give  a  common  structure  to  data 
in  the  Defense  Architecture  Repository  System  (DARS),  a  repository  through  which 
data  may  be  shared  with  other  architecture  communities.  Architectures  in  CERDEC ’s 
C4ISR  database  are  scoped  to  operational,  system,  and  technical  elements  in  Army 
Tactical  and  Operational  echelons  to  a  degree  of  fidelity  (e.g.  command  post,  platform/ 
vehicle,  staff  section,  dismounted  soldier)  that  corresponds  to  source  data  availability 
and  the  scope  of  the  architecture  analysis  being  conducted.  The  process  described  in  the 
following  sections  is  currently  implemented  from  the  dismounted  soldier  through  the 
Unit  of  Employment  and  can  further  scale  to  encompass  all  elements  within  the  Global 
Information  Grid  (GIG)  in  a  standardized  form  suitable  for  Joint  C4ISR  system-of- 
systems  analyses.  As  such,  the  intent  of  this  paper  is  to  offer  a  high-level  description  of 
CERDEC’s  integrated  architecture  methodology  for  peer  evaluation  of  its  applicability 
to  Joint  architectures  and  to  solicit  feedback  for  improvements  as  the  requirement  for 
system-of-systems  analyses  continues  to  grow  in  scope  and  fidelity. 


ARCHITECTURE  DEFINED 

In  an  integrated  architecture  framework,  all  of  the  operational  views  (OVs),  system 
views  (SVs),  and  technical  views  (TVs)  are  connected  and  consistent  with  one  another. 
The  relationships  between  the  views  are  what  define  the  actual  architecture,  and  it  is  the 
common  data  elements  among  the  views  that  provide  the  integration. 

Table  1  summarizes  the  definitions  (DoDAF,  2003)  for  each  type  of  view.  The 
all  view  (AV)  contains  high-level  summary  information  about  the  architecture  and 
includes  references  to  the  OVs,  SVs,  and  TVs  that  make  up  the  architecture.  Because 
the  architecture  products  are  specifically  developed  for  the  purpose  of  conducting 
analyses,  CERDEC  also  includes  in  the  AV-1  the  analysis  questions  being  addressed, 
lessons  learned,  and  tables  showing  OV/SV/TV  traceability  to  the  analysis  questions 
and  to  the  consumers/stakeholders,  respectively. 
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TABLE  1.  PRODUCTION  AND  ANALYSES  METHODOLOGY 


View 

Definition 

All  View  (AV) 

Overarching  aspects  of  an  architecture  that  relate  to  all  three  of 
the  views  (e.g.,  scope,  content). 

Operational  View  (OV) 

Description  of  the  tasks  and  activities,  operational  elements, 
and  information  exchanges  required  to  accomplish  or  support  a 
military  operation  (e.g.,  information  flows,  information  exchange 
requirements  [lERs]). 

Systems  View  (SV) 

Description,  including  graphics,  of  systems,  and  interconnections 
providing  for,  or  supporting,  warfighting  functions.  Associates 
physical  resources  and  their  performance  attributes  to  the 
operational  view  (e.g.,  platforms,  systems,  speed  of  service, 
maintainability,  availability,  priority,  security  classification). 

Technical  View  (TV) 

Minimal  set  of  rules  governing  the  arrangement,  interaction,  and 
interdependence  of  system  parts  or  elements,  whose  purpose 
is  to  ensure  that  a  conformant  system  satisfies  a  specified  set 
of  requirements  (e.g.,  technical  standards,  implementation 
conventions,  standards  options,  rules,  criteria). 

BASIC  TENETS  OF  C4ISR  ARCHITECTURE  ANALYSIS 

In  order  to  obtain  consistent  and  meaningful  analysis  results,  the  CERDEC 
integrated  architecture  methodology  and  its  implementation  in  the  TCAT  database 
are  based  on  fundamental  principles  of  C4ISR  architecture  development,  as  follows: 
The  process  used  to  create  the  architecture  is  an  integral  part  of  the  architecture 
itself.  A  clearly  defined  and  standardized  process  for  architectural  view  development 
is  employed  for  each  study  to  ensure  that  a  thoroughly  consistent  and  integrated 
architecture  is  produced.  Architecture  products  integrated  and  generated  using  TCAT 
are  dependent  upon  certain  practices  that  are  observed  throughout  the  architecture 
development  process.  These  practices  include  obtaining  relevant  reference  materials 
early  on,  utilizing  appropriate  subject  matter  expertise  to  extract  required  information, 
defining  the  relationships  among  key  operational  systems  and  technical  data  elements, 
and  documenting  assumptions  regarding  ambiguous  or  absent  source  data.  Thus,  the 
methodology,  reference  materials,  and  data  element  relationships  and  assumptions  are 
delivered  along  with  the  architecture  views  for  completeness  and  traceability. 

The  basis  of  all  architectures  is  the  User  s  needs.  The  input  of  the  specific  operational 
unit  for  which  the  architecture  is  being  generated  is  required  to  ensure  that  the  operational 
views  reflect  the  doctrinal  requirements  and  standing  operating  procedures  (SOPs)  of 
the  unit.  Also  required  are  the  specifics  on  how  that  unit  would  operationally  employ 
each  fielded  system  in  the  architecture.  The  modeled  unit’s  input  is  a  critical  part  of 
the  methodology  that  ensures  the  validity  of  the  architecture’s  operational,  system,  and 
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technical  views,  and  therefore  the  validity  and  applicability  of  the  resulting  C4ISR 
traffic  model  and  subsequent  analysis  results. 

Operational,  system,  and  technical  views  must  be  consistent.  All  products  defining 
the  same  architecture  are  related  and  connected.  An  internally  consistent  architecture 
will  have  technical  views  that  trace  back  to  its  system  views  and  system  views  that  trace 
back  to  its  operational  views.  Without  this  interconnected  traceability,  a  comprehensive 
identification  of  gaps  between  systems  and  operational  functions/needs,  and  the 
impact  of  those  gaps,  would  not  be  possible.  A  major  part  of  accomplishing  inherent 
consistency  within  an  architecture  is  the  early  identification  of  source  information 
needed  to  populate  all  of  the  relevant  framework  products.  This  source  information 
is  needed  to  understand  and  establish  relationships  among  the  source  data  elements 
that  populate  the  views  common  to  an  architecture.  Though  certain  source  data  values 
may  not  be  immediately  available,  it  is  important  to  anticipate  which  data  fields  (i.e. 
data  elements,  such  as  producer,  network  service,  security  classification,  etc.)  will 
be  subsequently  required  in  analysis.  Knowing  which  fields  will  be  necessary  in  the 
architecture  products  at  the  outset  of  a  study  allows  more  time  for  collecting  the  field 
values  and  reserves  placeholders  for  these  values  in  each  relevant  architecture  product. 
As  the  values  are  obtained,  the  architecture  views  are  populated  with  relevant  data. 
In  this  way,  the  architecture  products  are  used  as  vehicles  for  storing  and  relating  the 
data  needed  for  analysis,  and  any  change  made  in  one  view  automatically  propagates 
through  all  affected  views. 


METHODOLOGY  OVERVIEW 

Before  populating  a  single  architecture  product,  the  objectives  of  the  analysis  task 
and  the  questions  to  be  addressed  are  determined.  Once  the  purpose  of  the  analysis  is 
clearly  established  AV  products  are  drafted  to  document  the  scope  of  the  architecture, 
and  the  data  elements  necessary  to  complete  that  analysis  are  identified.  The  architecture 
framework  products  that  would  contain  those  elements  are  then  selected  as  appropriate 
vehicles  for  representing  the  data  elements  for  analysis. 

The  AV-1  (Overview  and  Summary  Information)  is  updated  throughout  the 
development  of  the  architecture  to  summarize  the  scope,  purpose,  context,  tools  and 
file  formats,  findings/recommendations,  and  issues/lessons  learned.  The  AV-1  serves 
two  related  purposes:  1)  it  serves  as  a  planning  guide  during  architecture  development, 
and  2)  upon  completion  of  the  architecture,  the  AV-1  is  revised  to  document  conclusions 
reached  from  the  overall  architectural  development  experience.  The  AV-2  (Integrated 
Dictionary)  keeps  track  of  terms  and  definitions  used  in  the  architecture.  This  integrated 
dictionary  consists  of  textual  information  in  the  form  of  a  glossary,  including  definitions 
of  acronyms  and  architectural  elements  (e.g.,  activities,  information  flows,  operational 
elements)  used  in  the  architecture.  The  AV-2  is  an  accompanying  reference  to  the 
other  products,  and  its  value  lies  in  the  provision  of  unambiguous  definitions  among 
developers  and  users  of  the  architecture. 

Once  the  initial  information  for  the  AVs  is  identified,  the  necessary  source  data 
is  assembled.  The  source  data  consists  of  the  elements  necessary  to  populate  the 


308 


architecture  framework  products  undergoing  analysis.  Since  CERDEC  uses  the  data  in 
architecture  products  in  M&S,  there  is  a  requirement  for  detail  not  commonly  captured 
in  existing  DoDAF  products.  This  detail  is  needed  in  the  operational  and  systems 
exchange  requirements  in  order  to  create  an  adequate  model  of  C4ISR  traffic  within 
an  operational  unit.  The  foundation  source  data  elements  that  are  used  to  construct  the 
architecture  are  as  follows: 

1 .  Force  Structure  Elements  -  Command  centers,  platforms/vehicles,  staff  sections,  or 
individual  soldiers  that  constitute  the  communicating  operational  entities  within  the 
organization.  Also  referred  to  as  Operational  Elements  or  Operational  Entities. 

2.  Operational  Tasks  -  Doctrinal  activities  performed  by  units  and  staffs  in  support  of 
a  mission,  extracted  from  the  Field  Manual  (FM  7- 1 5)  of  the  Army  Universal  Task 
Fist  (AUTF)  and  the  Chairman,  Joint  Chiefs  of  Staff  Manual  (CJCSM  3500. 04C) 
Universal  Joint  Task  Fist  (UJTF).  Operational  Tasks  are  also  sometimes  referred  to 
as  AUTLs/UJTLs. 

3.  ReMITs  (Reports,  Messages,  /SR,  Telemetry)  -  This  document  is  a  catalog  of 
approximately  570  specific  types  of  C4ISR  information  that  can  be  exchanged  on 
the  battlefield,  ft  serves  as  a  master  pick- list  of  messages  from  the  standard  Variable 
Message  Format  (VMF),  United  States  Message  Text  Formatting  (USMTF),  and 
Field  Manual  (FM  101-5-2)  of  U.S.  Army  Report  and  Message  Formats,  as  well  as 
Commander’s  Information  Requirements  (CIRs)  and  some  Future  Force  messages 
not  yet  documented  elsewhere.  This  master  list  was  compiled  with  definitions  by 
CERDEC  and  the  TRADOC  Analysis  Center  (TRAC),  and  is  formatted  for  use  in 
detailed  analyses.  This  information  is  also  referred  to  as  C4ISR  Products  or  C4ISR 
Information  Elements. 

4.  Format  Parameters  -  Each  ReMIT  has  a  specific  perishability,  cost  of  failure, 
precedence  and  security  classification.  ReMITs  may  occur  in  the  format  of  data, 
imagery,  voice,  and/or  vidstream.  Each  ReMIT  format  has  certain  parameters 
associated  with  it;  such  as  data  rate,  frequency,  size,  duration,  and  speed  of  service. 
The  values  for  the  Format  Parameters  provide  a  quantitative  value  to  each  ReMIT. 

5.  Systems  -  For  the  purposes  of  present  CERDEC  analyses,  a  system  is  the  sending 
or  receiving  end-user  application  or  piece  of  communications  equipment  in  the 
system  architecture  that  is  resourced  to  and  used  by  a  force  structure  element  in  the 
operational  architecture.  Systems  are  used  to  communicate  information  ReMITs 
from  producers  to  consumers  in  support  of  operational  requirements.  Systems  that 
have  been  represented  in  CERDEC  studies  include  the  Army  Battle  Command 
System  (ABCS)  applications  and  their  application  servers,  Voice  over  Internet 
Protocol  (VoIP)  phones,  generic  computers/laptops,  and  collaboration/VTC  equip¬ 
ment.  The  ABCS  includes  such  systems  as: 

•  Maneuver  Control  System  -  Fite  (MCS-F), 
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•  All-Source  Analysis  System  -  Lite  (ASAS-L), 

•  Global  Command  and  Control  System  -  Army  (GCCS-A), 

•  Air  and  Missile  Defense  Workstation  ( AMDWS), 

•  Integrated  Meteorological  System  (IMETS), 

•  Digital  Topographical  Support  System  -  Lite  (DTSS-L),  and  others. 

The  source  data  described  above  is  used  to  populate  architecture  framework  products 
that  are  either  mission  independent  or  mission  specific.  The  distinction  between  the 
two  types  of  products  is  summarized  in  Table  2. 

The  architecture  framework  products  associated  with  the  study  are  then  exported 
from  the  data  in  the  TCAT  database.  The  DoDAF  views  currently  able  to  be  generated 
using  TCAT  include: 

■  OV-2  (Operational  Node  Connectivity  Description), 

■  OV-3  (Operational  Information  Exchange  Matrix), 

■  OV-6b  (Operational  State  Transition  Description), 

■  OV-6c  (Operational  Event-Trace  Description),  SV-4  (Systems  Functionality 
Description), 

■  SV-5  (Operational  Activity  to  Systems  Function  Traceability  Matrix), 


TABLE  2.  FRAMEWORK  PRODUCT  DISTINCTIONS 


Mission-Independent  C4ISR  Exchanges 

Mission-Specific  C4ISR  Exchanges 

Developed  to  conduct  general  traffic  load 
analyses  (e.g.,  average  bandwidth  through 
systems,  into  and  out  of  operational  elements) 

Developed  to  conduct  analysis  on  a  specific 
mission  thread  (e.g.,  performance  of  the  mission 
thread  over  a  loaded  network) 

Regular  interval  traffic  used  to  load  the  network 

Each  exchange  is  associated  with  a  step  in  a 
mission  thread 

Unsequenced 

Chronologically  sequenced 

A  frequency  field  captures  an  average  rate  of 
occurrence  for  each  unique  exchange.  There 
are  no  time  stamps,  and  start/end  times  are 
arbitrary. 

Each  unique  exchange  occurs  only  once 
according  to  its  time  stamp.  The  first 
exchange(s)  in  the  sequence  starts  when  the 
mission  thread  is  triggered. 

100,000s  to  1,000,000s  of  unique  exchanges 
may  be  identified 

100s  to  1 ,000s  of  unique  exchanges  may  be 
identified 

Examples  of  traffic  include  common 
operational  picture  updates,  ISR  updates 

Examples  of  traffic  include  a  call  for  fire,  a 
battle  update  brief 

310 


■  SV-6  (Systems  Data  Exchange  Matrix),  and 

■  SV- 1  Oc  (Systems  Event-Trace  Description). 

Products  that  already  exist  for  an  architecture  undergoing  analysis  are  integrated 
into  the  database  and  augmented  as  needed,  prior  to  generating  the  higher  fidelity 
equivalent  products  utilized  in  M&S. 


TRAFFIC  PROFILE  DEVELOPMENT 

An  example  of  a  specific  type  of  analysis  that  CERDEC  ASEO  has  conducted 
highlights  the  use  of  both  mission  independent  and  mission  specific  products.  First,  a 
unit-specific,  mission  independent  product  referred  to  as  a  traffic  profile  is  developed. 
This  product,  populated  based  on  the  available  source  data,  is  used  to  estimate  the 
offered  load  of  background  traffic  on  the  C4ISR  network  being  analyzed.  Mission- 
specific  products,  referred  to  as  mission  threads,  are  then  layered  over  the  traffic  profile 
to  (among  other  uses  described  in  Lindy,  et  al.)  measure  the  performance  of  network 
services  associated  with  the  mission  over  the  C4ISR  network  that  is  already  loaded 
with  background  traffic. 

This  process  for  developing  the  traffic  profile  and  mission  threads  for  an  architecture 
utilizes  common  reference  data  as  well  as  the  same  set  of  relationships  established 
among  that  reference  data.  Because  the  source  data  is  common,  both  the  traffic  profile 
and  the  mission  threads  are  developed  to  the  same  degree  of  fidelity  for  a  given 
architecture. 

The  traffic  profile  consists  of  a  subset  of  mission  independent  information  exchanges 
between  producer-consumer  pairs  that  is  directly  traceable  to  the  operational  information 
exchange  requirements  and  is  required  for  modeling  application-level  user  traffic. 
It  contains  information  such  as  the  producing  and  consuming  operational  elements, 
ReMIT,  ReMIT  format  (data,  imagery,  voice  or  vidstream),  ReMIT  attributes  (data 
rate,  duration,  size,  frequency),  and  the  following  fields  not  captured  in  the  architecture 
products: 

1.  Network  Services  -  These  are  the  delivery  mechanisms  used  to  transport  ReMITs 
in  the  system  architecture.  Real-time  services  such  as  VoIP  and  Collaboration  (e.g. 
Video  Teleconferencing  [VTC],  whiteboarding,  text  chat,  etc.)  are  identified  in  the 
system  architecture  for  use  in  subsequent  performance  analyses,  whereas  non-real¬ 
time  services  such  as  Peer-to-Peer  (between  ABCS  systems),  E-mail,  and  Web/ 
TACWeb  are  identified  in  order  to  understand  the  network  load  over  which  the 
real-time  services  must  perform. 

2.  Network  -  This  field  identifies  the  physical  networks  that  are  used  to  transport 
the  individual  messages.  Unclassified  but  Sensitive  Internet  Protocol  Router 
Network  (NIPRNET)  and  Secret  Internet  Protocol  Router  Network  (SIPRNET) 
traffic  are  identified  based  on  ReMITs  and  their  security  classifications.  Joint 
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Worldwide  Intelligence  Communications  System  (JWICS)  and  Combat  Service 
Support  (CSS)  traffic  are  identified  based  on  ReMIT,  and  represent  Intelligence 
and  Logistics  information  respectively.  Relationships  of  Systems  and  C4ISR 
information  to  specific  Networks  are  used  to  analyze  the  load  on  each  Network  and 
explore  information  dissemination  concepts. 

To  create  a  traffic  profile,  operational,  systems,  and  technical  subject  matter  experts 
(SMEs)  first  set  up  source  matrices,  which  are  used  to  establish  relationships  among 
the  source  data  elements.  A  matrix  is  set  up  on  a  spreadsheet  by  listing  data  elements  of 
one  kind  down  the  first  column  and  data  elements  of  another  kind  across  the  first  row. 
The  cells  of  the  matrix  are  then  populated  to  show  the  relationship  between  two  data 
elements.  The  following  relationships  among  data  elements  constitute  the  principle 
matrices  used  by  CERDEC  to  construct  integrated  architecture  products,  including  a 
traffic  profile: 

1 .  Operational  Tasks  performed  during  Battle  Phases. 

2.  Force  Structure  Elements  performing  Operational  Tasks. 

3.  ReMIT s  required  to  execute  Operational  Tasks. 

4.  ReMITs  exchanged  by  Force  Structure  Elements. 

5.  Format  Parameters  associated  with  each  ReMIT. 

6.  Systems  resourced  to  Force  Structure  Elements. 

7.  Operational  Tasks  supported  by  Systems. 

8.  ReMITs  exchanged  by  Systems. 

9.  Network  Services  available  to  Systems. 

10.  Networks  available  to  Systems. 

The  matrices  allow  relationships  among  data  elements  to  be  assigned  in  a  consolidated 
manner,  and  are  the  key  to  producing  completely  consistent  architecture  views.  Note 
that  some  matrices  relate  system  architecture  data  to  operational  architecture  data,  so 
that  resulting  OVs  and  SVs  are  consistent  with  one  another.  (Technical  View  matrices 
are  being  integrated  in  2005.)  Furthermore,  the  matrices  are  set  up  to  be  modular, 
thus  enabling  architectural  updates  to  be  made  in  a  matter  of  hours  or  days  rather  than 
weeks  or  months,  allowing  the  effects  of  small  changes  to  be  studied  before  network 
configuration  decisions  are  made. 

The  following  is  a  brief  description  of  each  of  the  matrices  listed  above: 
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1.  Operational  Tasks  performed  during  Battle  Phases.  This  matrix  captures  the 
operational  tasks  (i.e.,  AUTLs  and/or  UJTLs)  that  are  performed  during  each  phase 
of  battle  (Objective  Force:  Unit  of  Employment  Concept,  7  August,  2002):  Entry, 
Shape,  Decisive,  and  Transition  (e.g.,  Conduct  Landing  Zone  Operations  during 
Entry  phase). 

2.  Force  Structure  Elements  performing  Operational  Tasks.  This  matrix  captures 
each  operational  task  performed  by  each  force  structure  element  according  to  the 
doctrinal  requirements  of  the  unit  being  analyzed  (e.g.,  3ID/UE-x/DIV  HQ/DTAC 
CP  1/ADA1  performs  Conduct  Landing  Zone  Operations). 

3.  ReMITs  required  to  execute  Operational  Tasks.  This  matrix  captures  all  C4ISR 
information  (Reports,  Messages,  ISR,  and  Telemetry),  known  in  short  as  ReMITs, 
needed  for  or  generated  by  the  completion  of  each  operational  task.  Some  tasks 
call  for  ReMITs  being  generated  (produced)  as  output  of  the  task,  and  some  tasks 
call  for  ReMITs  being  required  (consumed)  as  input  to  the  task.  This  matrix  just 
captures  the  doctrinal  association  of  the  ReMIT  s  with  each  task,  not  who  specifically 
is  producing  and  consuming  the  information  (e.g.,  an  INTSUM  (Intelligence 
Summary)  is  required  to  execute  Conduct  Landing  Zone  Operations). 

4.  ReMITs  exchanged  by  Force  Structure  Elements.  This  matrix  captures  each  ReMIT 
produced  and  consumed  by  each  force  structure  element.  This  defines  a  general 
flow  of  information  that  is  based  on  the  unit’s  standing  operating  procedures 
(SOPs)  (i.e.,  “business  practices”)  that  is  independent  of  mission  or  scenario.  This 
matrix  provides  the  average  C4ISR  production  and  consumption  at  each  element 
in  the  unit  for  use  in  subsequent  bandwidth  requirements  analyses.  This  matrix  is 
automatically  cross-referenced  with  both  the  “Force  Structure  Elements  performing 
Operational  Tasks”  and  the  “ReMITs  required  to  execute  Operational  Tasks” 
doctrinal  matrices  to  ensure  the  ReMIT  flows  defined  in  this  SOP  matrix  support 
the  operational  tasks  performed  by  each  element  in  the  unit.  If  any  inconsistencies 
are  found,  the  matrices  are  revisited  and  the  necessary  corrections  are  made  before 
generating  the  final  traffic  profile  that  is  used  in  analysis. 

5.  Format  Parameters  associated  with  each  ReMIT.  Each  ReMIT  may  occur  in  one 
or  more  formats',  data,  imagery,  voice,  or  vidstream.  Every  potential  format  of 
each  ReMIT  has  a  set  of  parameters  assigned  to  it:  frequency  of  occurrence  (per 
hour)  for  each  battle  phase,  security  classification,  precedence,  criticality,  and 
perishability.  In  addition,  size  (in  kilobytes,  before  system  and  network  overhead) 
is  populated  for  the  non-streaming  formats  of  data  and  imagery,  and  duration  (in 
seconds)  and  data  rate  (in  kbps)  are  populated  for  the  streaming  formats  of  voice 
and  vidstream.  These  format  parameters  quantify  each  ReMIT  so  that  the  C4ISR 
exchanges  can  later  be  simulated. 

6.  Systems  resourced  to  Force  Structure  Elements.  This  relationship  is  extracted 
directly  from  the  unit-specific  System  Architecture  (SA)  produced  by  the  Program 
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Executive  Office  Command,  Control  and  Communications  Tactical/Office  of  the 
Chief  Engineer  Knowledge  Engineering  Information  Laboratory  (PEO  C3T  OCE 
KEIL).  CERDEC  ASEO  and  OCE  KEIL  collaborate  to  load  the  TCAT  database 
with  data  from  the  SA  database  so  that  updates  to  the  KEIL  system  architecture 
are  reflected  in  the  CERDEC  analyses.  This  collaboration  allows  for  a  consistent, 
timely,  and  configuration-controlled  update  to  the  traffic  profile  upon  which  the 
analysis  is  based  and  will  eventually  be  expanded  to  allow  a  near  real  time  update 
to  both  the  data  and  the  analysis  results. 

7.  Operational  Tasks  supported  by  Systems.  This  set  of  mappings  is  used  to  help 
narrow  the  assignment  of  a  system  for  an  information  exchange.  It  includes  all 
the  operational  tasks  that  a  particular  system  would  be  used  to  support.  This 
information  is  provided  by  individual  system  subject  matter  experts. 

8.  ReMITs  exchanged  by  Systems.  This  set  of  mappings  is  used  to  assign  systems  to 
an  information  exchange.  It  ensures  that  an  information  exchange  is  assigned  to 
systems  that  are  capable  of  exchanging  it. 

9.  Network  Services  available  to  Systems.  This  is  a  set  of  mappings  that  are  combined 
with  programming  logic  to  determine  the  network  service  used  in  the  sending  and 
the  receiving  of  a  ReMIT.  Network  Services  include  VoIP,  Collaboration,  Tactical 
Web  (TACWEB),  E-mail,  Peer-to-Peer,  and  others.  A  different  set  of  network 
services  can  be  defined  based  on  the  needs  of  the  particular  analysis  of  the  given 
system  architecture. 

10.  Networks  available  to  Systems.  The  assignment  of  networks  is  based  on  the  system 
architecture  source  data  and  some  programmed  logic.  Network  examples  are  SIPR, 
NIPR,  JWICS  and  CSS. 

Once  the  basic  matrices  above  are  completed,  SQL  scripts  are  executed  to  generate 
the  traffic  profile  and  populate  all  the  architecture  products  at  once  with  the  appropriate 
information  required  for  each  view.  The  traffic  profile  contains  the  user-generated 
C4ISR  exchange  requirements  that  need  to  occur  no  matter  what  the  scenario  is  or 
where  the  unit  is  deployed.  Once  this  baseline  is  constructed,  customization  can  begin 
for  various  types  of  mission  specific  analyses. 


MISSION  THREAD  DEVELOPMENT 

Architecture  products  containing  mission-specific  data  can  be  layered  over  the  traffic 
profile  for  various  types  of  performance  analyses.  These  views  contain  sequenced 
events  among  operational  elements  of  the  force  structure  and  their  systems. 

The  mission-specific  products  are  built  using  the  same  source  data  as  used  in  the 
traffic  profile,  and  include  additional  information  such  as  thread  name,  sequence 


314 


number,  and  a  description  for  each  task  in  the  thread.  For  an  in-depth  description  of  the 
process  used  to  generate  mission-specific  products  (Lindy,  et  al.). 


PREPARING  THE  ARCHITECTURE  FOR  MODELING  &  SIMULATION 

Upon  final  compilation  of  the  architecture  data  for  a  given  analysis,  the  data  mined 
from  the  TCAT  database  (e.g.,  traffic  profile,  mission  threads)  are  formatted  for  more 
specific  M&S  excursions  to  test  the  behavior  of  the  network  under  various  operational 
and  technical  circumstances. 

The  architecture  products  and  the  traffic  profile  alone  do  not  capture  the  physical 
path  of  each  exchange.  They  only  capture  the  C4ISR  exchanges  that  are  associated  with 
the  end  user  (i.e.,  user  traffic  from  producer  to  consumer).  Internal  network  exchanges 
(i.e.,  network  traffic  among  intermediary  devices2  needed  to  accomplish  the  end  user 
exchanges  must  be  added  to  account  for  overhead  associated  with  dynamic  network 
management  traffic.  Describing  these  internal  exchanges  in  the  architecture  also  helps 
to  quantify  subsequent  analyses  of  information  dissemination  schemes. 


The  mission-specific  products  are  built  using  the  same  source 
data  as  used  in  the  traffic  profile ,  and  include  additional 
information  such  as  thread  name,  sequence  number,  and  a 
description  for  each  task  in  the  thread. 


The  completed  traffic  profile  serves  as  the  basis  for  deriving  the  service  flows  and 
the  application  control  profiles  used  for  the  bandwidth  and  performance  analyses, 
respectively.  In  generating  these  derivative  input  files,  first  the  server  dispositions/ 
locations  for  each  service  are  incorporated  into  each  data  set.  Secondly,  the  traffic 
is  aggregated  based  on  sender/receiver  pair  and  service.  Lastly,  the  data  is  translated 
into  the  formats  required  for  driving  the  flow  analysis  tool  and  the  OPNET  simulation 
models. 

At  this  point,  the  M&S  phase  of  the  analysis  is  entered.  Briefly  described,  the  data 
contained  in  the  traffic  model  contributes  to  architectural  analysis  enabled  by  M&S 
analysis.  Combined  withmodelsofcommunications  assets  and  network  services,  analysis 
questions  such  as  optimum  server  placement  to  minimize  bandwidth  requirements, 
performance  of  real-time  applications  (e.g.,  collaboration  tools  and  VoIP)  during  busy 
times  on  the  network,  and  suitability  of  a  proposed  Active  Directory  architecture  are 
addressed  in  flow  analysis  and/or  simulation  runs,  where  parameters  associated  with 
network  and  service  configurations  can  be  varied.  These  analysis  examples  merely 
touch  the  surface  of  questions  that  can  be  and  are  being  addressed  using  the  CERDEC 


CSAP&T  process.  Furthermore,  new  questions  continuously  arise  as  new  issues 
are  encountered  both  prior  to  unit  deployment  and  in  the  field.  The  structured  and 
repeatable  process  described  above  is  an  essential  component  to  CERDEC’s  capability 
of  adapting  to  changing  architecture  configurations,  and  its  ability  to  quickly  respond 
to  analysis  questions  in  time  to  be  of  help  to  the  end  user,  the  Warfighter. 


The  repeatability  of  the  methodology  and  the 
experiente  gained  in  implementing  it,  as  well  as  the 
availability  of  the  large  body  of  previous  work  are 
key  fattors  in  the  suttess  of  enabling  quirk  response 
analyses  required  by  an  Army  at  war : 


For  each  analysis  that  employs  the  CSAP&T  methodology,  the  body  of  work  created 
in  previous  analyses  is  leveraged  and  built  upon.  Volumes  of  documentation  are 
associated  with  each  analysis  activity,  and  include  the  data  sets,  reference  materials/ 
source  data,  assumptions,  methodology  description  and  study  overview.  Time- 
sensitive  analysis  results  are  distributed  to  stakeholders  at  regular  intervals  throughout 
the  analysis  as  technical  bulletins,  which  often  spur  new  questions  and  a  revisit  to 
the  analysis  to  conduct  additional  excursions  and  explore  possible  alternatives.  The 
repeatability  of  the  methodology  and  the  experience  gained  in  implementing  it,  as  well 
as  the  availability  of  the  large  body  of  previous  work  are  key  factors  in  the  success  of 
enabling  quick  response  analyses  required  by  an  Army  at  war. 


SUMMARY 

The  uniqueness  of  the  methodology  described  in  this  article  is  that  it  provides  a 
means  to  adapt  to  rapidly  changing  doctrine,  systems,  and  parameters  with  efficiency 
and  fidelity.  Since  much  of  the  data  is  first  created  independently  of  mission,  the  same 
data  may  be  reused,  customized,  and  applied  to  various  operational  scenarios,  missions, 
and  conditions.  All  architecture  data — regardless  of  its  operational,  system,  or  technical 
nature — is  designated  and  stored  in  one  common  database.  As  such,  consistency  among 
the  architecture  products  is  guaranteed.  Data  common  to  more  than  one  view  is  stored 
only  once  and  referenced  as  many  times  as  necessary.  Furthermore,  the  work  required 
to  update  the  architecture  is  minimized.  As  the  design  evolves,  the  source  data  and  the 
mappings  in  the  matrices  change.  Whenever  this  happens,  the  modular  nature  of  the 
matrices  allows  the  affected  portions  of  the  architecture  to  be  updated,  and  the  SQL 
scripts  are  re-run  so  that  all  the  views  are  updated  simultaneously.  Any  changes  to  data 
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in  one  view  propagate  through  to  all  affected  views.  This  approach  has  reduced  the 
turn-around  time  on  updating  highly  detailed  architecture  products  and  corresponding 
analysis  results,  from  months  to  days  or  even  hours,  allowing  “what  if”  studies  never 
before  possible. 

Since  it  is  now  possible  to  create  an  integrated  architecture  formatted  for  analysis  in 
less  time  using  the  above  methodology,  and  through  efficiencies  gained  by  collaboration 
with  organizations  such  as  the  KEIL,  the  CERDEC  has  applied  its  resources  towards 
conducting  the  C4ISR  systems  engineering  analyses  needed  to  make  recommendations 
regarding  the  architecture  to  DA  leadership,  PEOs  and  PMs,  as  well  as  the  end  customer/ 
user:  the  unit  itself.  Having  developed  a  structured,  repeatable  approach  to  integrating 
and  developing  architectures  as  well  as  the  foundational  skill  set  to  conduct  and  repeat 
various  types  of  analyses  in  2004,  the  ASEO  continues  to  evolve  its  process  to  a  level 
of  efficiency  such  that  analysis  results  can  be  obtained  and  used  to  support  traceable 
recommendations  prior  to  costly  hardware  development,  software  development, 
production  and  testing  takes  place. 

The  CERDEC  CSAP&T  methodology  is  embedded  in  doctrine,  customizable  to 
scenario,  geography,  systems  and  technology,  able  to  represent  Current  Force,  Modular 
Force,  or  Future  Force  task  organizations  and  able  to  produce  architectures  with  fidelity 
and  resolution  down  to  the  dismounted  soldier  and  up  through  Joint,  Coalition  and 
Strategic  domains.  Ultimately,  it  is  our  goal  to  have  all  OVs,  SVs  and  TVs  (as  well 
as  relevant  data  not  currently  captured  in  any  view)  in  a  single  automated  systems 
engineering  process  designed  for  system-of-systems  analysis,  whose  data  elements  are 
commonly  defined  across  the  Army  community  and  beyond. 
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END  NOTES 

1.  This  is  an  example  of  a  shorthand  description  that  hierarchically  represents  a 
force  structure  element,  and  is  read  from  right  to  left:  The  Air  Defense  Artillery 
(ADA)  element  (which  could  be  a  section,  platoon,  battery  or  staff  liaison  officer) 
in  Division  Tactical  Command  Post  1  (DTAC  CPI)  in  Division  Fleadquarters  (DIV 
FIQ)  in  Unit  of  Employment-x  (UE-x)  in  the  3rd  Infantry  Division  (3ID). 

2.  Intermediary  devices  include  servers,  routers,  switches,  and  other  network 
management  devices  comprising  the  actual  network  topology.  These  exchanges 
are  accounted  for  separately  in  the  traffic  and  simulation  models. 


ACRONYM  KEY 

(IN  ORDER  OF  APPEARANCE) 


DoDAF - 
CERDEC  - 

C4ISR  - 

SoS- 
RDECOM  - 
CSAP&T  - 
M&S  - 
ASEO- 
TCAT  - 
SQL  - 
XML- 
CADM- 
DARS- 
UE- 
GIG  - 
OV- 

sv- 

TV- 
AV- 
SOP- 
FM- 
CJCSM  - 
AUTL- 
UJTL  - 
ReMIT  - 

VMF  - 
USMTF  - 
CIR  - 


Department  of  Defense  Architecture  Framework 

Communications-Electronics  Research,  Development,  and 
Engineering  Center 

Command,  Control,  Communications,  Computer,  Intelligence, 
Surveillance,  and  Reconnaissance 

System-of-Systems 

Research,  Development,  and  Engineering  Command 

CERDEC  Systems  Analysis  Processes  and  Tools 

Modeling  and  Simulation 

Architecture  and  Systems  Engineering  Office 

The  Complete  C4I SR  Architectural  Tool 

Structured  Query  Language 

Extensible  Markup  Language 

Core  Architecture  Data  Model 

Defense  Architecture  Repository  System 

Unit  of  Employment 

Global  Information  Grid 

Operational  View 

Systems  View 

Technical  View 

All  View 

Standing  Operating  Procedure 
Field  Manual 

Chairman,  Joint  Chiefs  of  Staff  Manual 
Army  Universal  Task  List 
Universal  Joint  Task  List 

Reports,  Messages,  Intelligence/Surveillance/Reconnaisance, 
Telemetry 

Variable  Message  Format 

United  States  Message  Text  Formatting 

Commander’s  Information  Requirement 


TRADOC - 
TRAC- 
ABCS  - 
VoIP  - 
VTC  - 
MCS-L  - 
ASAS-L  - 
GCCS-A  - 
AMDWS  - 
IMETS  - 
DTSS-L  - 
TACWeb  - 
NIPRNET  - 
SIPRNET  - 
JWICS  - 
CSS- 
SMEs- 
3  ID  — 
UE-x- 
DIV  HQ  - 
DTAC  CPI  - 
ADA- 
SA- 
PEO- 
C3T  - 
OCE- 
KEIL  - 
DA- 
PM- 


Training  and  Doctrine  Command 

Training  and  Doctrine  Command  Analysis  Center 

Army  Battle  Command  System 

Voice  over  Internet  Protocol 

Video  Teleconference 

Maneuver  Control  System  -  Lite 

All-Source  Analysis  System  -  Lite 

Global  Command  and  Control  System  -  Army 

Air  and  Missile  Defense  Workstation 

Integrated  Meteorological  System 

Digital  Topographical  Support  System  -  Lite 

Tactical  Web 

Unclassified  but  Sensitive  Internet  Protocol  Router  Network 

Secret  Internet  Protocol  Router  Network 

Joint  Worldwide  Intelligence  Communications  System 

Combat  Service  Support 

Subject  Matter  Experts 

3rd  Infantry  Division 

Unit  of  Employment-x 

Division  Headquarters 

Division  Tactical  Command  Post  1 

Air  Defense  Artillery 

System  Architecture 

Program  Executive  Office 

Command,  Control,  and  Communications  Tactical 
Office  of  the  Chief  Engineer 
Knowledge  Engineering  Information  Laboratory 
Department  of  the  Army 
Program  Manager 
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